1. Field of the Invention
This invention relates, generally, to computer processing. More specifically, it relates to a hybrid asynchronous transmission process.
2. Brief Description of the Prior Art
Traditionally interacting with a Web application consisted of a user selecting a link on a web page, the browser flashing and beginning to postback to the server while the user waited for the page to be repainted. Much of the time, the new version of the page was the same as the previous version, with only a small portion being updated. This cycle was constantly repeated when using Web applications and was time consuming for even the fastest of connections.
The first attempt to prevent full webpage repainting was AJAX (Asynchronous JavaScript and XML). AJAX works through the browser and attempts to bring richness to Web applications through interactive workflows stemming from asynchronous communications to servers. The goal is to provide a user with the capabilities to interact with a webpage while the browser is communicating with a server in the background. Asynchronous communications are essential for activities that are potentially blocking, such as when applications access the web. Access to a web resource can be slow or delayed and if an activity is blocked within a synchronous process, the entire application must wait. In an asynchronous process, the application can continue with other work that doesn't depend on the web resource until the potentially blocking task finishes.
The AJAX technologies have changed the user's Web application experience. With the JavaScript code, the browser communicates asynchronously with the Web Server. A request to a server no longer results in the browser flashing and the user being unable to view and interact with the page. JavaScript receives the updated data from the server and modifies the page dynamically, using DHTML coding methodology. AJAX is providing users with a more responsive, desktop like experience.
Asynchrony proves especially valuable for applications that access the UI thread because all UI-related activity usually shares one thread. If any process is blocked in a synchronous application, all are blocked. Your application stops responding, and you might conclude that it has failed when instead it's just waiting. When using asynchronous methods, the application continues to respond to the UI. You can resize or minimize a window, for example, or you can close the application if you don't want to wait for it to finish. A typical asynchronous transmission process for a single asynchronous request can be seen in FIG. 1.
This creates problems of its own due to the stateless protocols including the Internet Protocol (IP) which is the foundation for the Internet, and the Hypertext Transfer Protocol (HTTP) which is the foundation of data communication for the World Wide Web. This fire and forget programming model works in Desktop applications since the application sticks around until the OS kills it, so whenever the asynchronous callback runs there is guaranteed to be a UI thread that it can interact with. In web applications, this model falls apart since requests are by definition transient. If the asynchronous callback happens to run after the request has finished, there is no guarantee that the data structures that the callback needs to interact with are still in a good state. Today's solution is to synchronize the asynchronous processing tasks. This design becomes very complicated quickly, especially if it is to be flexible and change dynamically based on the specific user's request. This solution also leaves us with two serious problems: (1) trips to the server (number of requests) and (2) UpdatePanels cannot be added, removed and added again without running the page. The solution results in a design which is heavy, static, expensive and difficult to program and maintain.
Accordingly, what is needed is a more efficient and effective asynchronous transmission process. However, in view of the art considered as a whole at the time the present invention was made, it was not obvious to those of ordinary skill in the field of this invention how the shortcomings of the prior art could be overcome.
All referenced publications are incorporated herein by reference in their entirety. Furthermore, where a definition or use of a term in a reference, which is incorporated by reference herein, is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
While certain aspects of conventional technologies have been discussed to facilitate disclosure of the invention, Applicants in no way disclaim these technical aspects, and it is contemplated that the claimed invention may encompass one or more of the conventional technical aspects discussed herein.
The present invention may address one or more of the problems and deficiencies of the prior art discussed above. However, it is contemplated that the invention may prove useful in addressing other problems and deficiencies in a number of technical areas. Therefore, the claimed invention should not necessarily be construed as limited to addressing any of the particular problems or deficiencies discussed herein.
In this specification, where a document, act or item of knowledge is referred to or discussed, this reference or discussion is not an admission that the document, act or item of knowledge or any combination thereof was at the priority date, publicly available, known to the public, part of common general knowledge, or otherwise constitutes prior art under the applicable statutory provisions; or is known to be relevant to an attempt to solve any problem with which this specification is concerned.